Method for managing resources of a link in a communication network

ABSTRACT

The invention concerns a method for managing resources of a link in a communication network comprising busses interconnected by at least one link to form a network in which the at least one link is transparent for some protocol layers of nodes connected to the busses.  
     The inventive method is characterized in that it comprises the step of making information of the resources available over the at least one link available to link-aware applications.

[0001] The invention concerns a method for managing resources of a link,which may be a wireless link, in a communication network, in particulara network comprising wired communication busses interconnected with thehelp of wireless links.

[0002] In a network comprising a plurality of interconnectedtransmission media, the bandwidth available over each transmissionmedium may not necessarily be the same.

[0003] If one considers for example two IEEE 1394 wired serial bussesconnected together using a 5 GHz ETSI BRAN HiperLAN 2 wireless link, thebandwidth available on each of the wired busses can be of 100 Mb/s ormore, while the bandwidth available over the wireless link may belimited to 30 Mb/s. Consequently, the wireless link constitutes abottleneck for connections using this link.

[0004]FIG. 1 is a diagram of one example of such a network. The networkcomprises two busses 11 and 12, connected to source device 13 and sinkdevice 14, respectively to sink device 15 and source device 16. Sourcedevice 13 is for example a digital VCR, while sink devices 14 and 15 aredisplays and source device 16 is a tuner. Bus 11 is also connected to aportal 17, while bus 12 is connected to a portal 18, both portalsforming a wireless link between busses 11 and 12. It is supposed thatthe wireless link is transparent to devices 13 to 16 at the level ofIEEE 1394, i.e. these devices have the impression that they are on thesame physical bus.

[0005] Supposing the available bandwidth on the wireless link is of 30Mb/s, a first connection of 20 Mb/s is established between the VCR 13and the display 15. A second connection between tuner 16 and display 14can be established, since the link is transparent to devices 16 and 14,but if the bandwidth required for this second connection is greater thanthe remaining wireless bandwidth, the display 14 will not display properpictures, if any at all. As far as the application having built thesecond connection is concerned, the connection was neverthelessestablished without incident at the IEEE 1394 level, because of thetransparency of the link at that level.

[0006] [Page 2a]

[0007] The object of the invention is a method for managing resources ofa link in a communication network comprising at least two bussesconnected to the link to form a network, wherein the network forms asingle virtual bus regarding the protocol used by a bus, said methodcomprising the steps of:

[0008] providing a link-aware application in a node of the network forobtaining link resource reservation information,

[0009] for establishment of a connection between devices over the link,accessing said information, and

[0010] determining whether the connection can be established as afunction of this information.

[0011] According to an embodiment, each link comprises a plurality ofportals, at least one portal of a link comprising said resourceinformation concerning its link.

[0012] According to an embodiment, the information comprises bandwidthavailable over the link. The information also comprises channelsavailable over the link.

[0013] According to an embodiment, an application establishes aconnection between two nodes of the network through the steps of:

[0014] (a) reserving a channel and bandwidth for the connection on thebusses;

[0015] (b) identifying links on the path between the nodes to beconnected;

[0016] (c) reserve resources for each link on said path if step (a) hasbeen successful.

[0017] According to an embodiment, the step of reserving resources foreach link comprises the step of:

[0018] having the application request the reservation of the samebandwidth and the same channel as reserved in step (a) from each link.

[0019] According to an embodiment, the step of reserving resources foreach link further comprises the steps of:

[0020] The document EP-A-0 933 900, discloses a method forinterconnecting 1394 busses by a 1394 bridge. In this document, each busand the bridge consists of an independent bus, and the method allow twonodes from different bus to make bandwidth and channel reservation toallow an isochronous communication between the two nodes. This methodconsists of making the three corresponding bandwidth reservation on eachindependent bus, the one hosting the emitting node, the bridge and theone hosting the receiving host.

[0021] Contrary to what is disclosed in this document, we are in thecase where the link that connects busses is transparent. That means,that a node on one bus sees all the nodes on the interconnected bussesas belonging to the same network.

[0022] by the application, sending identifiers of the nodes to beconnected to a portal of a link whose resources are to be reserved;

[0023] having the link determine whether the requested bandwidth isavailable, as a function of the nodes to be connected;

[0024] accept or reject the bandwidth reservation request as a functionof this determination.

[0025] According to an embodiment, the step of reserving resources foreach link further comprises the steps of:

[0026] having the link check the availability of the requested channel,and if a channel over the link is available, accept the channelreservation;

[0027] check whether a maximum number of reserved channels on the linkhas been reached and in the affirmative, rejecting any furtherreservation.

[0028] According to an embodiment, the step of providing a registershowing channel availability for the network and a register showingchannel availability for each link, wherein both registers comprise thesame number of channels, each link having a maximum number of channelswhich can be reserved in parallel, said maximum number being lower thanor equal to the number of channels in the registers, a portal providingthe resource information for a link checking, after a channelreservation has been accepted, whether the maximum number of channelswhich can be reserved in parallel has been reached, and in theaffirmative, modifying the register of the link in order to show noavailable channels for that link.

[0029] Other characteristics and advantages of the invention will appearduring the description of a non-restrictive embodiment explained withthe help of the attached drawings among which:

[0030]FIG. 1, already described, is a diagram of a network comprising awireless link and illustrating the bandwidth bottleneck constituted bythis link;

[0031]FIG. 2 is a diagram of a network according to the embodiment ofthe invention and comprising a wireless link and indicating the softwarestacks in portal devices constituting the wireless link, as well asregisters used for implementing the invention;

[0032]FIG. 3 is a flowchart of a method for reserving a channel using aregister indicating available channels over a wireless link;

[0033]FIG. 4 is a flowchart of a method for releasing a reservedchannel;

[0034]FIG. 5 is a diagram illustrating the reservation and use ofbandwidth over a link according to a variant embodiment of theinvention;

[0035]FIG. 6 is a diagram illustrating the release of bandwidth of FIG.5;

[0036]FIG. 7 is a diagram of a multi-portal link shared between networksof different type according to a variant embodiment of the invention;

[0037]FIG. 8 is a diagram of the network of FIG. 1, where the connectionof nodes to the busses have been modified in order to reduce use of thewireless link.

[0038] Although the embodiment is based on the use of an ETSI BRANHiperlan 2 wireless link, other technologies may be used. An example ofsuch a technology is a link implementing the Internet Protocol (‘IP’).Moreover, the links between wired busses need not necessarily bewireless, although this is the case in the embodiment described below.

[0039] Information on IEEE 1394 may be found in the documents IEEE1394-1995 and IEEE 1394a-2000 published by the IEEE.

[0040] 1. General Information

[0041] In order to simplify explanations, the embodiment will bedescribed with the help of figures illustrating links generallycomprising two portals each. Nevertheless, the invention also applies tolinks comprising more than two portals.

[0042]FIG. 2 represents a network formed of two IEEE 1394 busses (alsocalled device clusters) 21 and 22, each comprising a wired IEEE 1394bus, a plurality of devices (respectively nodes 23, 24, 29 and 25, 26,30) and a portal (for each bus, respectively 27 and 28) to the wirelessHiperlan 2 link. The nodes are IEEE 1394 devices. Applications are awareof the existence and location of the wireless link.

[0043] According to the present embodiment, the portals 27 and 28 arenot transparent to the other devices, in the sense that they are alsoconsidered to be nodes on their respective busses, i.e. they areattributed a physical identifier after a bus reset. At the level of theIEEE 1394 layers however, the link is transparent: all nodes areconsidered to be on a single bus and physical identifiers are attributedaccordingly after a reset. Portals 27 and 28 issue self identificationpackets to represent nodes on their respective clusters when bus resetsare carried out.

[0044] Each node comprises an IEEE 1394 software stack, i.e. thephysical layer, the link layer and the transaction layer, as well as anapplication layer. Each portal also comprises these layers on theirwired bus interface. Lastly, the portals communicate using the Hiperlan2 protocol stack.

[0045] 2. Link Resource Manager and Associated Registers

[0046] According to the invention, the portals make wireless linkrelated resource reservation information available to the applicationsof the nodes on the different clusters. According to the presentembodiment, this information includes available bandwidth and channelsover the link. This information is maintained in ‘wireless resourceregisters’ present in at least one of the portals of the wireless link,and can be accessed by the applications or the middleware of nodes onthe different busses.

[0047] It is known that a IEEE 1394 bus, as defined in the IEEE 13941995 standard, comprises what is called an Isochronous Resource Manager(or ‘IRM’) which maintains two registers, called ‘BANDWIDTH_AVAILABLE’and ‘CHANNELS_AVAILABLE’, respectively indicating the availablebandwidth on the bus and the available channels, among a maximum of 64isochronous channels.

[0048] Since according to the present embodiment the wireless link istransparent as far as the IEEE 1394 layers are concerned, a single IRMexists in the network.

[0049] The IRM BANDWIDTH_AVAILABLE register, as defined by the abovestandard, is given by table 1: TABLE 1 zeros bw_remaining 19 bits 13bits

[0050] The initial value of the bw_remaining is equal to 0x1333 (4915 inthe decimal system) bandwidth units. Each time an application of a nodewishes to reserve bandwidth on the wired bus, it checks this value anddecrements it by the required bandwidth if enough bandwidth isavailable. Else, the connection cannot be established.

[0051] The IRM CHANNELS_AVAILABLE register, as defined in the samestandard, is given by table 2. TABLE 2 channels_available_hichannels_available_lo 32 bits

[0052] The initial value of the register is 0xFFFFFFFF. Each bitrepresents the availability of a specific channel. The least significantbit of ‘channels_available_hi’ indicates the availability of the channel‘0’ and the most significant bit of ‘channels_available_lo’ representsthe channel ‘63’. Each time an application wishes to reserve a channel,it checks the register, chooses an available channel and sets thecorresponding bit of the register to ‘0’. When there are not sufficientchannels available, the connection cannot be established.

[0053] In order to reserve bandwidth or a channel, a register is firstread by an application through a Read request message. The applicationreceives a Read response message, which contains the content of theregister. After checking the availability of the requested resource, theapplication locks access to the corresponding register and writes theappropriate new value. This lock and write operation is carried out byhaving the application issue a Lock request and having the IRM sending aLock response. According to IEEE 1394 1995, the registers are accessedseparately. According to IEEE 1394 2000, the Read is not necessary sincethe Lock response gives back the actual value in case of bad argumentson the Lock request.

[0054] According to the present embodiment, a resource manager isimplemented at the link level. This resource manager will be called‘Link Resource Manager’ or ‘LRM’ in what follows, to distinguish it fromthe IRM defined by IEEE 1394 1995.

[0055] According to the present embodiment, the LRM is implemented inone of the portals of the wireless link. It manages two registers,LINK_BANDWIDTH_AVAILABLE and LINK_CHANNEL_AVAILABLE which indicaterespectively the bandwidth available over the wireless link and theavailable channels (in addition to other information).

[0056] The LRM LINK_BANDWIDTH_AVAILABLE register according to thepresent embodiment has the format given by table 3: TABLE 3 Source_PhyIDSink_PhyID f channel LRM_bw_remaining 6 bits 6 bits 1 6 bits 13 bits

[0057] The ‘LRM_bw_remaining’ field has a signification similar to thatof the bw_remaining field of the IRM BANDWIDTH_AVAILABLE register. Giventhe fact that the bandwidth available over the link is different fromthat available on a wired bus, the initial value of this parameter isdifferent. If the bandwidth over the link is lower, the initial value inthis field will also be lower, and if the available bandwidth is higher,then it will never reach zero when reservations are made, since thelimiting factor will be the bandwidth on the busses connected to thewireless link.

[0058] The ‘Source_PhyID’ field contains the physical identifier of thesource device. The ‘Sink_PhyID’ field contains the physical identifierof the sink device. The contents of these fields are defined by anapplication making a reservation (using the Lock request message), withthe purpose of informing the LRM of the identity of the talker (source)node and of the listener (sink) node. Knowing these identifiers, the LRMcan determine the actual available bandwidth which, as will be explainedfurther on, may be different from that indicated in the‘link_bw_remaining’ field of the LRM_BANDWIDTH_AVAILABLE register.

[0059] According to a variant embodiment, the Source_PhyID andSink_PhyID fields of the request contain the physical identifiers of theportals between which a connection is to be reserved.

[0060] In wireless links with more than two portals, the bandwidthavailable between any two portals may be different, being for examplefunction of the quality of transmission between portals. The LRM has toknow which two portals are to be part of a connection in order toindicate the real bandwidth available between these two portals. Theportals may be deduced by the LRM from the identities of the talker andlistener nodes. The bandwidth indicated by the ‘link_bw_remaining’ fieldmay thus in certain cases not reflect the real bandwidth availablebetween any two portals.

[0061] According to the present embodiment, the ‘link_bw_remaining’field indicates the largest bandwidth available between any two pairs ofportals of the wireless link. An application can thus immediatelydetermine that a reservation of bandwidth is not possible if the amountit requests is greater than the amount indicated in the‘link_bw_remaining’ field. In all other cases, the LRM first calculatesthe bandwidth available between the two portals concerned by thereservation and eventually grants or rejects the reservation in the Lockresponse, giving in the response the real bandwidth available betweenthe source and the sink in the link_bw_available field.

[0062] According to a variant embodiment, the ‘link_bw_remaining’ fieldcontains a dummy value which is larger than the bandwidth anyapplication could request. In this case, it is always the LRM whichrejects a reservation of bandwidth, since the application cannot deduceany valid bandwidth information from its Read request.

[0063] In case wireless links are strictly limited to two portals, thebandwidth available over the link is not a function of the source andsink devices. According to a variant embodiment, in a network comprisingsuch links, the first two fields of the LRM LINK_BANDWIDTH_AVAILABLEregister are not required. Nevertheless, the use of these fields is alsopossible on two-portal wireless links.

[0064] The ‘channel’ field contains the number of the channel requestedby the application making the reservation. This number is the same asthe one which has already been allocated in the CHANNEL_AVAILABLEregister of the IRM since, as will be seen later, the application firstmakes a reservation with the IRM of the IEEE 1394 network before makingreservations with the LRMs of the wireless links. The content of thefield is provided to the LRM through the Lock request for accessing theLRM LINK_BANDWIDTH_AVAILABLE.

[0065] The ‘f’ field contains a flag indicating the availability of therequested channel over the link. This field is used in the Lock responseto indicate whether the requested channel is available (‘0’) or not(‘1’). It is set by the LRM.

[0066] The LRM LINK_CHANNELS_AVAILABLE register has the format definedby table 4. It is similar to the format of the IRM CHANNELS_AVAILABLEregister, although it functions in a different way. TABLE 4 0 31link_channels_available_hi link_channels_available_lo 32 32 bits 63

[0067] The register's contents have the same meaning as those of theIRM's CHANNELS_AVAILABLE register.

[0068] The wireless link may allow a maximum number of channels whichwill be lower or higher than the boundary of 64 channels of an IEEE 1394bus. Even if the link admits a higher number of channels compared to theIEEE 1394 channels, only the latter number will be used, since the IRMof the IEEE 1394 network will be limited to this number.

[0069] If the wireless link admits a lower number of channels, thefollowing algorithm will be used. This algorithm is illustrated by FIG.3 for the reservation mechanism and FIG. 4 for the release mechanism.

[0070] The link_channels_available (link_channels_available_hi andlink_channels_available_lo) bits have to be set to ‘1’ as initialvalues.

[0071] When an application requests a channel which is free to beallocated by the link's LRM and which is not the last possible one, thereservation of that channel is accepted and the channel's flag is set to‘0’.

[0072] When an application requests a channel and this channel is thelast available one for the link (although there might still be availablechannels at the CHANNELS_AVAILABLE register of the IRM), the reservationof the channel is accepted, and all flags of the LINK_CHANNELS_AVAILABLEregister are set to ‘0’, in order to show that there are no morechannels available through this link.

[0073] The LRM keeps in memory the list of channels of the registerwhich have indeed been reserved by an application, as compared to thosechannels which are simply made unavailable because of the restrictionsimposed by the wireless link.

[0074] When an application releases a channel, the specified channel'sflag is set to ‘1’. If the link was fully reserved, this channel releasealso triggers the setting of all non-reserved channels' flags to ‘1’.

[0075] The LINK_CHANNELS_AVAILABLE register is not managed the same wayas the CHANNELS_AVAILABLE register of the IRM. It will accept Readrequests, but not Lock requests. An application can thus check whetherchannels remain available over the wireless link. The actual channelreservation will be made by the LRM following an application's Lockrequest on the LINK_BANDWIDTH_AVAILABLE register.

[0076] 3. Register Use

[0077] The LINK_BANDWIDTH_AVAILABLE register has more functions thanjust indicating the available bandwidth. When read using a Read request,it returns the bandwidth available on the link, but a Lock requesttriggers not only the reservation of bandwidth, but also the reservationof a channel. The LINK_CHANNELS_AVAILABLE register then needs only to beaccessed in Read mode, not in Lock mode.

[0078] An application wishing to make a reservation first carries outreservations with the IRM, and then uses the obtained channel number andreserved bandwidth to make reservations over the wireless links betweenthe source and sink nodes.

[0079] When performing a Lock request on the LINK_BANDWIDTH_AVAILABLEregister, the caller has to provide the ‘PhyID’ value of the sourcedevice on the IEEE 1394 network, the PhyID of the sink device on the1394 network, the required channel (this channel having already beenallocated by the IRM), and the new bandwidth value, i.e. the value readduring the Read request, decremented by the amount to be reserved.

[0080] With one message (i.e. the Lock request), all allocations areperformed (bandwidth as well as channel). The source and sink PhyIDs areused by the link LRM if it has the capability to process differentbandwidths between its portal devices.

[0081] The behavior of the LINK_BANDWIDTH_AVAILABLE register can bedescribed with the help of tables 5 to 7, respectively showing theinitial values, values obtained following a Read request and valuesobtained following a Lock request. TABLE 5 Initial values zeros zeros 0zeros 4915 or less 6 bits 6 bits 1 6 bits 13 bits

[0082] TABLE 6 Read values zeros zeros 0 zeros link_bw_remaining 6 bits6 bits 1 6 bits 13 bits

[0083] TABLE 7 Lock effect ignored ignored i ignored conditionallywritten 6 bits 6 bits 1 6 bits 13 bits

[0084] When a Read request is performed, the link_bw_remaining value isreturned in the Read response.

[0085] A Lock request comprises the value of the bandwidth previouslyread (‘arg_value’ field according to the IEEE 1394 1995 vocabulary), aswell as the new bandwidth value (‘data_value’). The LRM compares thecurrent value of the link_bw_remaining field with the value received inthe Lock request. If these values are equal, the reservation mayproceed, since no other request was granted between the current Read andLock requests. The new bandwidth value written into thelink_bw_remaining field will not necessarily be the value sent in theLock request and in the Lock response, because of the calculation rulesfor multi-portal links mentioned previously. In other words, the nextRead request may not necessarily result in the remaining bandwidth valuesent with the last Lock request.

[0086] The reasons for a possible failure of the Lock request onLINK_BANDWIDTH_AVAILABLE register are:

[0087] 1. The bandwidth available on the link was changed in theinterval between the current Read and Lock requests, and so the‘arg_value’ of the Lock request is not valid. The LRM manages thissituation in the same way as the IRM.

[0088] 2. The bandwidth available between the source and the sink overthe link is not sufficient. This may not have been detected when readingthe register because the value given back in the link_bw_remaining fieldmay be the available bandwidth for the best transmission over the link.A link with different bandwidth capacities depending on the portalsconsidered may then reject the Lock giving back the real bandwidth onthe path between source and sink PhyIDs, since the LRM knows the PhyIDsfrom the Lock request message and can then calculate the true bandwidthavailable for this particular connection.

[0089] 3. The required channel is no more available. This is onlypossible when another application allocates another channel (because therequested one is already allocated at the IRM), and this other channelwas the last available channel on the link, although some channels mayremain free in the IRM's CHANNELS_AVAILABLE register. In this case, theconnection cannot be established by the link's LRM. The LRM sets the ‘f’bit to ‘1’ in the Lock response in order to reflect this.

[0090] The behavior of the LINK_CHANNELS_AVAILABLE register can bedescribed with the help of tables 8 and 9, respectively showing theinitial values, values obtained following a Read request and valuesobtained following a Lock request: TABLE 8 Initial values ones ones 32bits

[0091] TABLE 9 Read values last successful lock on theLINK_BANDWIDTH_AVAILABLE register last successful lock on theLINK_BANDWIDTH_AVAILABLE register 32 bits

[0092] In case an application fails to obtain the required reservationsfrom any of the LRMs of the links between the source and sink nodes, ithas to request deallocation of already reserved resources.

[0093] 4. Example of Use of the LINK_BANDWIDTH_AVAILABLE Register

[0094] In what follows, an example of use of theLINK_BANDWIDTH_AVAILABLE register of the LRM is given, described withthe help of tables 10 to 16. It is supposed that in the frame of thisexample, the link supports a maximum of two channels.

[0095] The initial value of the register is given by table 10, taking atotal available bandwidth of 4915 units as an example. TABLE 10 zeroszeros 0 zeros 4915 6 6 1 6 13

[0096] The application of node 23 of FIG. 2 wishes to allocate a channeland bandwidth across the link between the node 23 (source) and the node25 (sink). First, it requests allocation of a channel and bandwidth atthe IRM, following IEEE 1394 1995 rules. The allocated channel is forexample channel number 7, and the bandwidth is 500 units. Then theapplication of node 23 performs a Lock request on theLINK_BANDWIDTH_AVAILABLE register of the LRM, the parameters of whichare shown in table 11. TABLE 11 Source Sink Channel Bandwidth arg_value0 0 0 0 4915 data_value 23 25 0 7 4415 6 6 1 6 13

[0097] If the Lock is accepted (and the LINK_CHANNEL_AVAILABLE registeris updated), the response is as given by the parameter of table 12.TABLE 12 new_value 23 25 0 7 4415 6 6 1 6 13

[0098] Then the application of node 26 decides to allocate a channel andbandwidth across the link, between the node 26 (source) and the node 24(sink). It is supposed that a reservation has already been made with theIRM. As an example, the channel is channel number 33, and the requiredbandwidth is of 1000 units. At the same time, the application of node 25performs a Lock request at the LRM for channel 12 and 2000 bandwidthunits between source node 29 and sink node 30, as indicated by table 13.TABLE 13 arg_value 0 0 0 0 4415 data_value 29 30 0 12 2415 6 6 1 6 13

[0099] If the Lock is accepted (and the LINK_CHANNEL_AVAILABLE registeris updated), the response is that given by table 14. TABLE 14 new_value29 30 0 12 2415 6 6 1 6 13

[0100] The Lock request of the application of node 26 will be rejectedbecause this link can only provide two channels. TABLE 15 arg_value 0 00 0 4415 data_value 26 24 0 33 3415 6 6 1 6 13

[0101] The Lock response is rejected and the fields of the registerbecome: TABLE 16 new_value 26 24 1 33 2415 6 6 1 6 13

[0102] The ‘f’ flag is set to ‘1’, indicating that there are no morechannels on this link. The link_bw_remaining field shows the lastupdated value, i.e. after the grant of the request of application ofnode 25.

[0103] The Lock responses contain the values of the Source_PhyID,Sink_PhyID and Channel fields to help the caller in retrieving what itasked for.

[0104] The following operations may be carried out when reserving orreleasing resources:

[0105] “Allocate New”:

[0106] This operation consists in allocating a new channel and aquantity of bandwidth. The channel is available and free, the requiredbandwidth is available. The operation is called an allocation becausethe previously read value of bandwidth transmitted with the request(‘arg_value’) is greater than the new value to be written into thelink_bw_remaining field (‘data_value’). The channel_available flag isset to ‘0’.

[0107] The LRM memorizes the relation between the channel and theallocated bandwidth.

[0108] According to a variant embodiment, a channel may be reservedwithout bandwidth. Such a possibility may be portal vendor dependent.

[0109] “Allocate More”:

[0110] This operation consists in allocating additional bandwidth to apreviously allocated channel, if sufficient bandwidth is available. TheLRM identifies such an operation by the fact that the channel number ofthe Lock request corresponds to a channel which is already allocated.The requested differential of bandwidth is added to the bandwidthalready reserved for this channel. The channel_available flag remains at‘0’. The portal cannot prevent applications from reserving bandwidth onalready allocated channels to send another stream which would causecollision on the bus (as in 1394-1995).

[0111] “Release Full”:

[0112] This operation consists in releasing a channel as well as thebandwidth allocated for this channel. The LRM identifies the operationas a release because the ‘arg_value’ field of the Lock request(containing the result of the Read request) is lower than its‘data_value’ (containing the new value to be written into thelink_bandwidth_available field). The fact that the release of resourcesis a full release is shown by the fact that the difference between thetwo previous fields is equal (or greater) to the bandwidth allocated forthis channel. The channel's flag in the LINK_CHANNELS_AVAILABLE registeris set to free (‘1’). In case the Lock request indicates a release ofmore than the allocated bandwidth, only the allocated bandwidth isreleased.

[0113] “Release Some”:

[0114] This operation consists in releasing only part of the bandwidthfor a given channel. The LRM identifies the requested operation as arelease through the fact that the ‘arg_value’ of the bw_remaining fieldof the Lock request is lower than its ‘data_value’, and that it ispartial because the difference is lower than the bandwidth allocated forthis channel. The channel remains reserved (the corresponding flag keepsthe value ‘0’) in the LINK_CHANNELS_AVAILABLE register. The releasedbandwidth is subtracted for the channel and the LRM keeps track of it.

[0115] In case all channels available over a link are reserved, allflags of the LINK_CHANNELS_AVAILABLE register are set to ‘0’. The LRMnevertheless keeps a list of the channels which have truly been reservedas compared to those which are just marked as such in the register. Whena Lock request for an ‘Allocate More’ operation is received by the LRM,the latter will allocated additional bandwidth only if the requestcorresponds to a truly reserved channel.

[0116] 5. Example of Use of the LINK_CHANNELS_AVAILABLE Register

[0117] An example illustrating the use of the LINK_CHANNEL_AVAILABLEregister will now be given, described with the help of tables 17 to 21,which show the contents of the register at different times. According tothis example, the wireless link has a capacity of three channels.

[0118] Initially, no channel over the wireless link is used. The stateof the LINK_CHANNELS_AVAILABLE register is given by table 17: TABLE 17 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

[0119] A first application reserves for example channel 7. The state ofthe register after the allocation is given by table 18. TABLE 18 1 1 1 11 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

[0120] A second application then reserves channel 33. The register'sstate becomes: TABLE 19 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1

[0121] There is only one available channel left on this link. When athird application allocates channel 2, the register's state becomes:TABLE 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

[0122] As the link cannot provide more channels, all channel flags areset to ‘0’. If a fourth application reads the register of this link, itwill deduce that no further channel can be reserved.

[0123] Now if the second application releases the channel 33, theregister's state becomes: TABLE 21 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1

[0124] One channel is now available on the wireless link: flags of allunused channels are set to ‘1’.

[0125] Advantageously, the fact that a channel needs to be reserved withthe global IRM first guarantees that there will be no conflict regardingthe identification of a channel to be reserved over a plurality ofwireless links. It is not possible to reserve a channel with an LRM ifit has not been allocated first by the IRM.

[0126] The applications of the network may or may not be aware of thewireless links. In case a non-link aware application builds a connectionincluding one or more wireless links, the LRMs of these links may makethe reservations of the required resources by themselves, or accordingto a variant, gives priority to connections made by link-awareapplications.

[0127] 6. Methods for Connection Establishment

[0128] Here is a short presentation of several connection methods that alink aware application uses according to the present embodiment. Themethods concern the opening of a connection, the destruction of aconnection, the re-establishment of a connection after a bus reset, andthe overlaying of a connection over an existing connection.

[0129] At several instances in the methods below, an application needsto obtain the topology of the network, in order to determine whether oneor several links on which resources are to be reserved are on the pathbetween the talker node and the listener node.

[0130] A topology map may be obtained by an application from the IEEE1394 physical layer, which establishes such a map after a bus reset. Themap indicates how the different nodes are connected.

[0131] According to the present embodiment, each portal comprises in itsmemory an identifier which designates it as a portal. Once anapplication has obtained the topology map—this is required only onceafter a reset—it accesses the memories of all nodes on the network inorder to determine whether these nodes are portals or not. A link isidentified when two portals are detected in series in the topology map.

[0132] 6.1 Opening a Connection

[0133] To open a connection, an application has to:

[0134] 1. Determine the topology map of the network, and check if one orseveral links are on the path between the source node and the sink node.

[0135] 2. Perform a Read request on the output Plug Control Register(‘oPCR’, as defined in IEC 61883, describing isochronous streamtransmission over a IEEE 1394 bus) of the source node to obtain therequired bandwidth, if this information was not given by the callerclient (i.e. the application).

[0136] 3. Perform Read requests on:

[0137] the IRM BANDWIDTH_AVAILABLE register (to obtain the quantity ofavailable bandwidth on the IEEE 1394 network)

[0138] the IRM CHANNELS_AVAILABLE register (to obtain the list ofavailable channels on the IEEE 1394 network)

[0139] the LRM LINK_BANDWIDTH_AVAILABLE register for each link crossedby the connection (to obtain the quantity of available bandwidth overeach link)

[0140] the LRM LINK_CHANNELS_AVAILABLE register for each link crossed bythe connection (to check channel availability)

[0141] the input Plug Control Register (‘iPCR’ as defined in IEC 61883)of the sink node to verify that it is free and can receive a stream

[0142] 4. Perform Lock requests on:

[0143] the IRM BANDWIDTH_AVAILABLE register (to reserve bandwidth on theIEEE 1394 network)

[0144] the IRM CHANNELS_AVAILABLE register (to reserve a channel on theIEEE 1394 network)

[0145] 5. If the requests were successful, perform Lock requests on:

[0146] the LRM LINK_BANDWIDTH_AVAILABLE register for each link crossedby the connection with the source PhyID, the sink PhyID and the channelnumber already allocated at the IRM (in order to reserve bandwidth oneach link)

[0147] the oPCR of the source (in order to modify this register so thatit shows the existence of the connection)

[0148] the iPCR of the sink (in order to modify this register so that itshows the existence of the connection)

[0149] 6.2 Closing a Connection

[0150] To close a connection, an application has to:

[0151] 1. Perform Read requests on:

[0152] the oPCR of the source to verify that it is not overlaid (i.e.there is only one listener node part of the connection)

[0153] the IRM BANDWIDTH_AVAILABLE register

[0154] the LRM LINK_BANDWIDTH_AVAILABLE register for each link crossedby the connection

[0155] 2. Perform Lock requests on

[0156] the IRM BANDWIDTH_AVAILABLE register

[0157] the IRM CHANNELS_AVAILABLE register

[0158] the LRM LINK_BANDWIDTH_AVAILABLE register for each link crossedby the connection

[0159] the oPCR of the source node

[0160] the iPCR of the sink node

[0161] 6.2 Reestablishing Connections After a Network Reset

[0162] The bus reset is propagated by the links. An application whichbuilt a connection is aware that a bus reset occurred, wherever itoriginated. The re-establishment basically follows the same rules as thecreation of a connection. The LRM registers are reset the same way asthe IRM registers.

[0163] 6.3 Overlaying a Connection

[0164] To overlay a connection, an application has to:

[0165] 1. Obtain the topology map, and check if one or several links areon the path between the source node and the sink node, and deduce whichones are already reserved for the connection.

[0166] 2. Perform a Read request on the oPCR of the source to know therequired bandwidth (if it was not given by the caller client).

[0167] 3. Perform Read requests on:

[0168] the LRM LINK_BANDWIDTH_AVAILABLE register for each link crossedby the connection and not already reserved, (to obtain the quantity ofavailable bandwidth over each link)

[0169] the LRM LINK_CHANNELS_AVAILABLE register for each link crossed bythe connection and not already reserved, (to check channel availability)

[0170] the iPCR of the sink node to verify that it is free

[0171] 4. Perform Lock requests on:

[0172] the LRM LINK_BANDWIDTH_AVAILABLE register for each link crossedby the connection and not already reserved, with the source PhyID, thesink PhyID and the channel number already allocated at the IRM.

[0173] the oPCR of the source node

[0174] the iPCR of the sink node

[0175] Using the above, an application may detect whether a connectionmay be established or not, and what link failed to provide thesufficient resources. According to methods that are not the purpose ofthe present description, the application may suggest modifications ofthe topology of the network in order to avoid failed connections.

[0176]FIG. 8 represents the network of FIG. 1, in which sources 13 and16 have been connected to busses 12 and 11 respectively, in response toan application's indication to a user.

[0177] 7. Improvement of the Bandwidth Use

[0178] If a first application reserves a bandwidth of 20 Mb/s over aHiperLAN 2 link offering 30 Mb/s, but uses only 10 Mb/s, 10 Mb/s ofbandwidth are wasted. A second application requiring 15 Mb/s cannot makea reservation.

[0179] According to a variant of the embodiment, a link's LRM verifiesthe real use of bandwidth by an application compared to the reservedbandwidth and makes the difference available for allocation to anotherapplication.

[0180]FIG. 5 shows a vertical bar representing the bandwidth availableover a link. For the purpose of this example, the total availablebandwidth is of ten units. For each channel reserved by an application,the LRM maintains two parameters. The first parameter (labeled ‘R’ inwhat follows) represents the reserved bandwidth. The second parameter(labeled ‘O’) represents the difference between the reserved bandwidthand the bandwidth really used by the application on the channel. Orepresents the optimized bandwidth for this channel.

[0181] According to the example of FIG. 5, three applications (A1, A2,A3) reserve bandwidth sequentially. The values near the letters R and Orespectively represent the bandwidth values for each application.

[0182] The first application A1 reserves three units on channel 7 (step1), but the LRM determines that it uses only one. It sets the parameterO for A1 to the value two (step 2). Application A2 then reserves fourunits on channel 33 (step 3), but uses only two: the parameter O forthis application also takes on the value two (step 4). Lastly,application A3 reserves four units on channel two and uses them entirely(step 5). Thus three units may be allocated to further applications, andthe LRM sets a new link_bw_available value appropriately.

[0183]FIG. 6 represents the bandwidth of FIG. 5 when applications startreleasing bandwidth. Since applications are not aware of the fact thatthe bandwidth they reserved has not been totally set apart for theiruse, they will release the reserved amount using appropriate Lockrequests.

[0184] Suppose the application A1 wishes to release its channel andbandwidth (step 6). It will send a Lock request trying to increase thelink_bw_available value, equal to three, by three units. The LRM willsimulate to the application A1 the release of three units, using apositive Lock response comprising the link_bw_available value increasedby three units, but will effectively increase this value only by theactually used amount of units, i.e. one. A similar concept applies forthe release of resources for A3 and A2.

[0185] According to this procedure, an application may have to use inits Lock request bandwidth values which are greater than the maximumbandwidth given in the LINK_BANDWIDTH_AVAILABLE register. For example,during step 8, in order to release four units of bandwidth, applicationA2 will use the desired value (‘data_value’) of twelve in its Lockrequest, since the current value of the register is of eight.

[0186] A release of bandwidth by an application must nevertheless notresult in the use of a bandwidth value exceeding 0x1FFF, since thisrepresents the greatest value which may be coded on the 13 bits reservedfor this purpose. Consequently, an LRM should not provide an improvementof bandwidth on one channel of more than 0x1FFF minus the maximumbandwidth available over the link.

[0187] For example, with a link bandwidth of 0x1333, the maximumimprovement for any one channel should not exceed 0xCCC.

[0188] 8. Interconnection of a Plurality of Networks Using a Single Link

[0189] According to a variant embodiment, a link is used simultaneouslyby several types of networks. FIG. 8 is a diagram of a link comprisingfour portals 74 to 77. Portals 74 and 75 are connected respectively totwo IEEE 1394 busses 70 and 71. Portals 76 and 77 are connectedrespectively to two IP networks 72 and 73. The two busses 70 and 71 areconnected in a transparent manner by the link, i.e. at lower layers allbus devices are considered to be on a single bus. The same is true forthe two IP networks: all IP devices are considered to be on a single IPnetwork. The resulting networks of busses 70/71 and of IP networks 72/73ignore each other's existence. They nevertheless share the use of theresources of the link formed by portals 74 to 77. Portals may all beincluded in a single device, or may be formed by separate devices (inthe case of a wireless link for example).

[0190] The portals have to allocate bandwidth resources to both networktypes. According to the present embodiment, separate LRMs are providedfor each type of network. In the case of the present example, one LRM isprovided for the network of IEEE 1394 busses, and one LRM is providedfor the IP networks. The two LRMs are called LRM-1394 and LRM-IP in whatfollows. The interface provided by the LRM-IP to IP devices need not bethe same as that provided by the LRM-1394 to IEEE 1394 nodes.

[0191] Since both LRMs allocate the same resources, they exchangeinformation regarding allocation of resources, depending on the actualimplementation of the link.

[0192] It has been previously mentioned that the bandwidth used over thelink between two busses for example generally cannot exceed thebandwidth available on the busses, even if the link's capacity isgreater. In the present case, the fact that several networks compete forthe same resources will have a limiting effect for a given network onlyunder certain circumstances.

[0193] The following cases are taken into account:

[0194] The link bandwidth is higher than the IEEE 1394 bandwidth.

[0195] In this case, reserving bandwidth on the IP networks will notdecrease the bw_remaining value of the LINK_BANDWIDTH_AVAILABLE registerof the LRM-1394, until the bandwidth reserved by the IP networks willlet the total link bandwidth drop lower than 0x1333 bandwidth units(IEEE 1394 units).

[0196] The same behavior applies for the channels.

[0197] The reverse is true (i.e. bandwidth and channel reservation bythe IEEE 1394 network).

[0198] 9. LRM Election

[0199] The invention works with point-to-point links (comprising only apair of portals per network) but also with multi-point links (comprisingmore than two portals per network). In both cases, two possibilitiesexist for the choice of the LRM device in a given network: one portal(for each of the networks) takes the role of the LRM, and everyapplication is sending messages to this device; or each applicationsends messages to the portals it is connected to, and a private protocolinside the link synchronizes the portals.

[0200] In other words, in the first cases, the LRM is managed by asingle portal elected among all candidate portals, the elected portalbeing known to the applications, while in the second case, no electiontakes place and the applications do not know where the LRM is locatedand simply send requests to their nearest portal.

[0201] These two possibilities will now be described in case the networkcomprising the link is a network of IEEE 1394 busses.

[0202] (a) Single LRM Portal Election

[0203] One portal takes the role of LRM. The election is carried outduring a network or bus reset. Two alternative methods for electing theLRM portal will now be described. The first method is based on ananalysis of the network topology. The second method is based on adecision made by the portals, followed by an announcement or exposure ofthe physical identifier of the elected LRM to applications.

[0204] Topology algorithm:

[0205] According to this method, the portal having the greatest PhyIDvalue among the candidate portals is elected LRM. This algorithm has theadvantage of being very simple, since the topology is readily availablefrom the IEEE 1394 layers. After each bus reset, applications have tocheck the topology to determine the new LRM for each link.

[0206] Private Link choice:

[0207] This method implements a dynamic protocol “inside” the link (i.e.between the portals, according to a protocol which may be specific tothe link), which means that the LRM can change after a bus reset (forexample if the portal which was LRM is removed).

[0208] Furthermore, in order to let the IEEE 1394 applications knowwhich node represents the LRM, a specific entry has to be defined in theconfiguration memory (‘config rom’) of the portals. This new entry willexist in the config rom of all the portal devices.

[0209] The format of the memory entry according to the present exampleis given by table 22. Other formats are possible. TABLE 22 8 bits 1 bit6 bits Key_ID = 30₁₆ s reserved Phy ID

[0210] ‘s’ is the synchronization bit. When it is set to ‘1’, the Phy IDvalue is considered not up-to-date, and is currently changing. This mayhappen for example after a bus reset. When it is equal to ‘0’, the PhyID value represents the Phy ID of the LRM for this link. The method ofupdating of the Phy ID value is private to the link.

[0211] (b) No LRM Portal Election

[0212] According to this second method, each application sends messages(i.e. Read and Lock requests) to the portal it is connected to. Eachportal implements the LRM registers. A private protocol inside the linkhas to carry out the synchronization between the portals to avoid theconflicts of simultaneous multiple Lock requests.

1. Method for managing resources of a link in a communication networkcomprising at least two busses connected to the link to form a network,wherein the network forms a single virtual bus regarding the protocolused by a bus, said method comprising the steps of: providing alink-aware application in a node of the network for obtaining linkresource reservation information, for establishment of a connectionbetween devices over the link, accessing said information, anddetermining whether the connection can be established as a function ofthis information.
 2. Method according to claim 1, wherein the link-awareapplication gets said information from one of the portals connectingbusses to the link.
 3. Method according to claim 2, wherein saidinformation comprises bandwidth available over the link.
 4. Methodaccording to claims 2 or 3, wherein said information comprises channelsavailable over the link.
 5. Method according to claim 4, wherein anapplication establishes a connection between two nodes of the networkthrough the steps of: (a) reserving a channel and bandwidth for theconnection on the busses; (b) identifying links on the path between thenodes to be connected; (c) reserve resources for each link on said pathif step (a) has been successful.
 6. Method according to claim 5, whereinthe step of reserving resources for each link comprises the step of:having the application request the reservation of the same bandwidth andthe same channel as reserved in step (a) from each link.
 7. Methodaccording to claim 6 wherein the step of reserving resources for eachlink further comprises the steps of: by the application, sendingidentifiers of the nodes to be connected to a portal of a link whoseresources are to be reserved; having the link determine whether therequested bandwidth is available, as a function of the nodes to beconnected; having the link determine whether the requested bandwidth isavailable, as a function of the nodes to be connected; accept or rejectthe bandwidth reservation request as a function of this determination.8. Method according to claim 7, wherein the step of reserving resourcesfor each link further comprises the steps of: having the link check theavailability of the requested channel, and if a channel over the link isavailable, accept the channel reservation; check whether a maximumnumber of reserved channels on the link has been reached and in theaffirmative, rejecting any further reservation.
 9. Method according toclaim 7, comprising the step of providing a register showing channelavailability for the network and a register showing channel availabilityfor each link, wherein both registers comprise the same number ofchannels, each link having a maximum number of channels which can bereserved in parallel, said maximum number being lower or equal to thanthe number of channels in the registers, a portal providing the resourceinformation for a link checking, after a channel reservation has beenaccepted, whether the maximum number of channels which can be reservedin parallel has been reached, and in the affirmative, modifying theregister of the link in order to show no available channels for thatlink.